The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Networks and internetworks that are based on Transmission Control Protocol and Internet Protocol (TCP/IP) rely on the Internet Control Message Protocol (“ICMP”) for handling error conditions in the network. ICMP is defined in RFC (Request for Comments) 792 of the Internet Engineering Task Force (IETF). Routers, switches and other network elements that participate in an internetwork or the global Internet use ICMP to exchange error-handling information. ICMP agents running on such network elements can generate error messages, such as ICMP destination unreachable messages, and informational messages, such as ICMP echo request and reply messages.
The response taken by a router upon receiving an ICMP error message packet depends on a type value carried in the ICMP packet. No authentication of the source of an ICMP packet is required in RFC 792, and implementations of ICMP do not provide such authentication. Most implementations of ICMP do verify the IP addresses and sometimes the TCP port numbers that are carried in ICMP packets, but this level of verification is insufficient to prevent most kinds of attacks. As a result, spoofed ICMP packets can give a false impression of error conditions, causing routers to respond in an unwanted manner to the non-existent error conditions. Certain responses can result in denial of service to clients, or poor quality of service. Therefore, network administrators desire to have a way for a router or other network element to determine the authenticity of an ICMP packet before performing a responsive action.
The following is an example of how disastrous results can be caused by just one spoofed ICMP packet. Path MTU discovery (PMTU) is a method used by TCP to intelligently discover the path maximum transmission unit (MTU) for a particular connection. The objective is to find the MTU value for a path, in order to use that MTU value for the TCP segment size, rather than the default TCP segment size of 536. PMTU seeks to find a minimum MTU that is higher than 536, hence resulting in higher throughput of data along the path.
PMTU discovery is performed by sending ICMP packets in which the “Do Not Fragment” (DF) bit in the IP header is set and having successively higher segment size values. A smaller MTU is discovered when an ICMP “unreachable”-type packet is received that includes the MTU of the interface that caused an error for the specified segment size value. The corrective action taken by a TCP implementation is to use the MTU value that is embedded in the ICMP packet for the next few minutes, after which a higher value is attempted. Using the same MTU value for ten (10) minutes is typical.
However, the ICMP unreachable packet is easily spoofed by an unauthorized or malicious party. The only specific information needed to spoof this packet is a four-tuple of values comprising two IP addresses and two port numbers. One port number is typically a well-known port number, and the other port number can be guessed readily because most TCP implementations simply increment the well-known port number to create port numbers for successive connections. Further, a malicious party often can obtain the IP addresses of routers participating in TCP connections from Border Gateway Protocol (BGP) flow maps that are published within the Internet.
TCP hosts are allowed to accept MTU values as low as 68, reflecting 28 bytes of data after accounting for 40 bytes of TCP-IP header data. Therefore, a spoofed ICMP packet that advertises an MTU of 70 bytes will cause a TCP implementation to use 30 bytes as the segment size for the 10 minutes. Receiving and processing another spoofed ICMP packet with an MTU of 70 after ten minutes will result in continuing the connection in a throttled condition for another 10 minutes.
Examples of TCP applications using PMTU include BGP and FTP, which often need to exchange large amounts of data. These applications and others may be vulnerable to the attacks described herein. For protocols like BGP, packet transmission time is extremely critical, and throttling a connection can cause disastrous consequences. Implementations of TCP in the FreeBSD operating system, and derivatives of FreeBSD, are believed to be vulnerable to the attack identified above. Many other TCP stack implementations exhibit the same exploitable behavior. Under version 6 of the Internet Protocol (IPv6), ICMP packets are used in the neighbor discovery process, path MTU discovery, and the Multicast Listener Discovery (MLD) protocol. IPv6 routers use MLD to discover multicast listeners, comprising nodes that want to receive multicast packets destined for specific multicast addresses, on directly attached links. A value of 58 in the Next Header field of the basic IPv6 packet header identifies an IPv6 ICMP packet. A similar identifier is used in IPv4. ICMP packets in IPv6 are like a transport layer packet in the sense that the ICMP packet follows all the extension headers and is the last piece of information in the IPv6 packet.
Within IPv6 ICMP packets, the ICMPv6 Type and ICMPv6 Code fields identify IPv6 ICMP packet specifics, such as the ICMP message type. The value in the Checksum field is derived from the fields in the IPv6 ICMP packet and the IPv6 header. The ICMPv6 Data field contains error or diagnostic information relevant to IP packet processing.
Both ICMPv4 and ICMPv6 are often blocked by security policies implemented in corporate firewalls because of attacks based on ICMP. There is no widespread technique in use for preventing network attacks based on ICMP for routers that use IPv4. While ICMPv6 has the capability to use IPSec authentication and encryption, which decrease the possibilities of an attack based on ICMPv6, the deployed base of IPv4 routers is very large, and these routers need a solution for preventing ICMP-based attacks.
Under RFC 792, IPv4 ICMP error packets comprise a copy of the IP header of the original packet that generated an error, and at least eight (8) bytes of data from the payload of the original IP packet. In one prior approach, the IP addresses carried in the IP header, and the TCP port numbers carried in the transport header, if present, are used to select a particular application or service in the router. However, this prior approach does not perform any form of authentication on the packet.